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OBJECT LIFETIME CONTROL IN AN OBJECT-ORIENTED MEMORY PROTEC- 
TION MECHANISM 

CROSS REFERENCE TO RELATED APPLICATIONS 

Application SN d7 /vs^ ^ST (D-1256) filed en- 
titled "Disabling Tag Bit Recognition and Allowing Privi- 
leged Operations to Occur in an Object-Oriented Memory Pro- 
tection Mechanism", assigned to Intel Corporation, the as- 
signee of the present invention. 

Application s/ ^r, b 2t> (D-1258) filed l$/ll/s><i entitled 
"Synchronous Communication Between Execution Environments in 
a Data Processing System Employing an Object-Oriented Memory 
Protection Mechanism", assigned to Intel Corporation. 

Application SN oVv^^S (D-1259) filed en- 
titled "Type Management and Control in an Object-Oriented 
Memory Protection Mechanism", assigned to Intel Corporation, 
the assignee of the present invention. 

BACKGROUND OF THE INVENTION 

Field of the Invention 

The invention relates to data processing systems, and more 
particularly to a memory-accessing system which deallocates 
objects stored in memory in accordance with assigned object 
lifetimes. 

Description of the Related Art 

Modern computer systems are organized such that all informa- 
tion within the system is represented by hardware-recog- 
nized, memory-resident information structures called ob- 
jects. This is known as an object-oriented computer archi- 
tecture. An object is a package of data that is a represen- 
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tation of related information maintained in a contiguously- 
addressed set of memory locations. 

In an object-oriented programming system, each type or class 
of object has a set of operations that are permitted to be 
performed on the objects that are members of the class. 
This is known as an object-based access mechanism. The in- 
ternal structure of objects is hidden from the programmer. 
The programmer can manipulate the objects only with the per- 
mitted operations. Access to an object is by means of a 
pointer to the object called an access descriptor. An ac- 
cess descriptor describes the kind of representation (rep) 
rights (such as read rights or write rights) which define 
the various kinds of access to the object that are permitted 
by the holder of the access descriptor for that object. 

The above described mechanisms allow many processes running 
on the system to have access to a very large shared data 
space. When a process terminates, objects stored in the 
shared data space need to be reclaimed (made available for 
use again). This is usual ii done at wvr eat expense in terms 
of operating system overhead by a process known as "garbage 
collection". This involves perhaps an additional processor, 
operating concurrently with the main processor, which de- 
tects and collects garbage. It must identify those objects 
whose content is no longer useful for the task in progress 
and make the associated memory locations available again for 
some other use. This can be very time consuming and there- 
fore expensive in term of processing overhead and reduced 
throughput. 

It is an object of this invention to provide a mechanism for 
identifing those objects associated with a process whose 
content is no longer useful and make the associated memory 
locations available again for some other use when the pro- 
cess terminates. 
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It is a furhter object of this invention to provide a mech- 
anism for assigning a lifetime to objects associated with a 
process to thereby enable the implicit deallocation of cer- 
tain objects and to prevent dangling references if access 
descriptors which point to objects with shorter lifetimes 
are stored in objects with longer lifetimes. 

SUMMARY OF THE INVENTION 

Briefly, the above objects are accomplished in accor- 
dance with the invention by providing an object table object 
(42), a page table directory object (60), and a page table 
object (44). Each of the objects is comprised of words, 
the words being either access descriptors (30) or data words 
(32). Each access descriptor includes an object index for 
selecting an object in an the address space of the proces- 
sor's memory, and a rights field specifying the permissible 
operations on an object selected by the access descriptor. 
The object table object (42) is stored at an address acces- 
sible by th- processor upon processor initialization and has 
stored therein object descriptors for use by the processor 
in forming physical addresses to the page table directory 
object (60) . Each of the access descriptors has a lifetime 
bit indicating the lifetime of an object specified by the 
access descriptor and the object storage descriptor has a 
lifetime bit indicating the lifetime of the object selected 
by the access descriptor. 

SUMMARY OF THE INVENTION 

Briefly, the above objects are accomplished in accor- 
dance with the invention by providing an object table object 
(42) , a page table directory object (60) , and a page table 
object (44). Each of the objects is comprised of words, 
th words being eith r access descriptors or data words. 
Each access descriptor includ s an object ind x for select- 



ing an object in an the address space of the processor's 
memory, and a rights field specifying the p rmissible oper- 
ations on an object selected by the access descriptor. The 
object tabl object (42) is stored at an address accessible 
by the processor upon processor initialization and has 
stored therein object descriptors for use by the processor 
in forming physical addresses to the page table directory 
object (60) . Each of the object descriptors includes a 
first encoded field (52) specifying the base address of the 
object referenced by the object descriptor and a second en- 
coded field (50) which includes object entry type. The page 
table (44) has stored therein page table entries for use by 
the processor in forming physical addresses to the paged ob- 
ject (38) and each page table entry has a page rights field 
(81). The offset (22) includes a page index (PI) used to 
index into a selected page table to locate the page table 
entry, and a page offset (PO) used in conjunction with a 
base address (79) stored in the page table entry to locate a 
datum entry in the paged object (38) . Each of the access de- 
scriptors has a lifetime bit indicating the lifetime of an 
object specified by the access descriptor and the object 
storage descriptor or page table entry has a lifetime -bit 
indicating the lifetime of the object or page selected by 
the access descriptor and offset. 

The invention has the advantage that objects can be re- 
claimed without resort to the expensive process of garbage 
collection. With the support of the local lifetime, it is 
possible to reclaim all local objects associated with a spe- 
cific local execution environment (process) without the 
overhaed of garbage collection when the local environment 
terminates . 
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Bri f Description of the Drawings 

The for going and other objects, features, and advantages of 
the invention will be apparent from the following detailed 
description of a preferred embodiment of the invention, as 
illustrated in the accompanying drawings wherein: 

FIGURE 1 is a block diagram of the processor registers and 
of system objects for supporting object addressing and pro- 
tection ; 

FIGURE 2 is a more detailed block diagram of the object off- 
set of FIGURE 1; 

FIGURE 3 and FIGURE 4 together comprise a diagram of a stor- 
age descriptor within the object table of FIGURE 1; 

FIGURE 5 is a diagram of the page table directory entry 
(PTDE) within the page table directory FIGURE l; and, 

FIGURE 6 is a diagram of the page table entry (PTE) within 
the page table FIGURE 1; 

FIGURE 7 is a diagram of lifetime protection checking logic; 

FIGURE 8 is a diagram of the execution logic of an am- 
plify_rights instruction and a restrict_rights instruction; 

FIGURE 9 is a diagram of data flow within the amplify rights 
logic of FIGURE 8; and, 

FIGURE 10 is a diagram of data flow within the restrict 
rights logic of FIGURE 8. 
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Description of the Preferred Em bodiment; 



The microprocessor in which the present invention may be em- 
bodied is shown in more detail in patent application SN 
07/455,625 d-1256) . To summarize briefly, the microprocessor 
is logically subdivided into the following major units: an 
Instruction Fetch Unit, an Instruction Decoder and Microin- 
struction Sequencer, a Translation Lookaside Buffer, a Local 
Bus Sequencer, and an Integer Execution Unit 'and Floating 
Point Unit. 

The Translation Lookaside Buffer (TLB) performs the address 
translation needed to implement virtual memory mechanisms. 
The address translation and memory protection uses an asso- 
ciative table of storage descriptors and page table entries. 
The TLB contains an address cache, an address adder, and 
memory protection checking hardware. 

Execution Modes 

As described in patent application SN 07/455.625 (D-1256) , the 
system provides two modes of execution, User mode and Super- 
visor mode, to support the efficient emulation of con- 
ventional operating systems. The system does not define 
the notion of privileged instructions. All instructions can 
be executed in either mode. A program gains privilege by 
nature of its access representation (rep) rights and its ex- 
ecution mode. The page rep rights in the current linear ad- 
dress space are interpreted differently depending on the ex- 
ecution mode. Storage used by the operating system gener- 
ally has page rep rights which do not allow user access, but 
may be read-only or read/write in the Supervisor mode. 

An instruction (14) in the memory may contain an address 
(20) which is a virtual memory address to the object (38) . 
The address is stored in a processor register (11) in the 
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processor. The address includes an offset (22) and an ac- 
cess descriptor (24). The access descriptor (24) is a 32- 
bit word which has a tag bit (33) . The acc ss descriptor 
includes an object index (34) and a rights field (35) . The 
object index provides an offset into an object table (42) 
which contains storage descriptors for objects stored in the 
memory, one of the objects being a page table (44). The de- 
scriptor includes an encoded field (50) and- a base address 
(52). An object is described by an object table entry in 
the object table (42) which provides the mapping information 
for the physical addresses of the storage blocks and pages 
which together represent the physical objects. For a simpl 
object, the object is represented by a block in physical ad- 
dress space directly. The physical base address (52) is 
stored in the object table entry. The information within 
the object is located by using a simple offset in the vir- 
tual address . 

A paged object is represented by a set of physical pages us- 
ing a single-level page table. A bi-paged -sb j ect (38) is 
represented by a set of physical pages using a page table 
(44) and a page table directory (60). The object table en- 
try for a paged object, called a paged object descriptor, 
contains the physical base address (61) of the page table 
directory (60), which is an array of page table directory 
entries for the page tables, including page table (44) . The 
page table directory entry is found by indexing using the 
page table directory index (DI) located in the offset (22) . 
The page table entry is found by indexing using the page in- 
dex (PI) located in the offset (22). The bi-paged object 
entry is found by indexing using the page offset (PO) lo- 
cated in the offset (22) . 



Object Addressing 



Three different address spaces are defined, Logical Address 
Space, Virtual Address Space and Physical Address Space. 
The Logical Address Space is accessed with a Linear Address 
which includes an Object Selector and an Object Offset. The 
Virtual Address Space is accessed with an Object Index and 
an Object Offset. The Physical Address Spacers accessed 
with an Object/Page Table Entry and Block/Page Offset. 

A logical address space is mapped onto a virtual address 
space which is mapped onto a physical address space. An ad- 
dress in each space has a unique structure as described be- 
low. 

Physical Address Space 

The physical address space covers read-write memory, read- 
only memory, and memory-mapped I/O. Communication with the 
physical world is in terms of physical addresses. The phys- 
ical address space is byte addressable and must guarantee 
atomic and indivisible access (read or write) for memory ad- 
dresses that are aligned according to the size of the ac- 
cess, i.e. a word access must be aligned to a word boundary. 
An indivisible access guarantees that a processor reading or 
writing a set of memory locations will complete the opera- 
tion before another processor can read or write the same lo- 
cation. An atomic operation allows a processor to read and 
modify a set of memory locations with the guarantee that 
another processor doing an atomic operation on the same 
block will be delayed. 



Virtual Address Space 

The virtual address space is a collection of independent 
dress spaces called objects. Any datum within an object 
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located by a simple offset. The virtual address of the da- 
tum is specified by two components: an object index that se- 
lects the desired address space and an object offset that 
selects the datum within the address space. The size of the 
virtual address space is the product of the number of ob- 
jects allowed and the maximum size of each object. 

An object is also defined as the unit of protection. To con- 
trol access within the virtual address space, the system 
protects and restricts the generation of object indices. An 
access descriptor (AD) , is defined to contain an object in- 
dex. The system protects the AD pointer by not allowing or- 
dinary data to be used to represent it. An access descrip- 
tor (AD) can point to any of the objects in the virtual ad- 
dress space. The virtual address is, therefore, specified 
by a protected object index (i.e. an access descriptor) and 
an unprotected offset into the object. 

Logical Address Space 

Access descriptors, directly or indirectly accessible, are 
conceptually assembled in sets to form yet a third type of 
address space called a logical (or instantaneous) address 
space. The logical address space defines the visibility of 
the execution environment. Logical addresses are mapped 
onto the single virtual address space. For maximum flexibil- 
ity, two types of logical addresses are defined: linear ad- 
dress and structured address. 

The first type, the linear address, is defined by four ob- 
jects that form the execution environment. A linear address 
is used to represent the conventional notion of a process 
address space. Linear addresses, interpreted within a given 
environment, are mapped onto the virtual address space. The 
mapping of linear address s to virtual addresses is a fun- 
damental part of the instruction interpretation process. In 
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a linear address, an operand specifier supplies only an off- 
set- the current linear address space is implied. The up- 
per two bits of a linear address implicitly selects one of 
the four objects that define the execution environm nt, 
while the remaining 30 bits is an offset into the selected 
object. 

The second type, the structured address, is defined by a 
virtual address (ie. access descriptor plus offset). The 
structured address is used to invoke advanced object-ori- 
ented protection features. In a structured address, an 
operand specifier supplies a virtual address. Since the sys- 
tem does not allow specifying an AD directly in the in- 
struction stream, the AD part of the virtual address must be 
specified indirectly using an AD selector in an operand 
specifier within the instruction. An AD selector specifies 
an AD stored locally in the processor registers. This lim- 
its the instantaneous addressability of objects to those ac- 
cessible by the ADs in the processor registers only. 

Accvts Descriptors and their Rights 

An access descriptor (AD) is a protected pointer to an ob- 
ject in the address space. The system protects access de- 
scriptors from accidental or malicious creation and modifi- 
cation. 

A program cannot address an object directly, but only indi- 
rectly via an access descriptor in the execution environ- 
ment. Since a program cannot reference an object without an 
access descriptor to it, a program's visibility can be re- 
stricted to only those objects it needs to access. 

An access descriptor contains the following information: 
Object Index, Rights, and Lifetime bit. The Object Index 
selects the object. The rights specify read rights, write 
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rights and type rights in an AD. The rights indicate the 
permissible operations on the object. Rights are associated 
with an access descriptor and not with the object itself. 
It is thus possible to have different rights to the same ob- 
ject by selecting different access descriptors. The Life- 
time bit indicates the lifetime of the object that an AD 
references. 

AD to Object Mapping 

Objects are referenced using access descriptors which are 
system-wide protected pointers. The object index (34) in 
an access descriptor selects an object table entry (OTE) in 
the system wide object table object (42) . An object table 
entry specifies the location, size, type, etc. of the refer- 
enced object. 

Storage Blocks and Pages 

An object is physically composed of a storage block and/or a 
set of pages. A block is a contiguous area in the physical 
address space. A block can be used to represent a simple ob- 
ject, a page table, or a page table directory. 

The base address of a storage block points to the first vis- 
ible byte of the block. The base address of a storage block 
must be aligned on a 64-byte physical address boundary. The 
length of a block varies from 64 bytes to 4096 bytes. A 
block cannot span across a 4K byte boundary. 

An object can also be represented by a set of pages with one 
or two level (s) of page tables. The first level table can 
be a storage block instead of a page. The pages that de- 
fine the bi-paged object (38) are described by the page 
table (44). A page is a fixed size block of 4K bytes with 
base address aligned on a 4K-byte boundary. 
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Tagging 

An object may contain access descriptors and/or data, i.e. 
any binary information. Access descriptors and data can re- 
side in the same object and can be interleaved in any arbi- 
trary order. In some systems, a tag bit is associated with 
each 4 -byte aligned word in memory to indicate whether the 
word is data or possibly a valid access descriptor. A valid 
access descriptor must be aligned to a 4 -byte boundary with 
a its tag bit set to one. A tag bit of zero is used to in- 
dicate that the word contains data or an access descriptor 
that cannot be dereferenced, that is cannot be used to ref- 
erence the contents of an object. 

In some systems, the tag bit is not available. In such sys- 
tems, the interpretation of a word as data or an access de- 
scriptor depends upon the operation. 

In a word-aligned read or write of the whole word, the tag 
bit is either preserved or set to zero depending on the op- 
eration. In an non-word aligned read, or a partial read of a 
word, the tag bit of the returned value is always forced to 
zero. The data manipulation (arithmetic or logical) 
instructions generate results with tag bits forced to zero, 
independently of the tag bits of the source operands. Tag- 
ging is described more fully in patent application SN 
07/455.625 (D-1256) . 

Typed Objects 

The internal organization of certain objects is defined by 
specifying and interpreting data structures within their ad- 
dress spaces. These objects play a key role in the protec- 
tion system, the interprocess/ interprocessor communication 
system, and th storage management system. To recognize 
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these system-defined objects and to control their use, ach 
one may be identified by a code. The code is called the 
object type and it is maintained with the object's addr ss 
mapping information. The present invention allows users to 
invent their own object types and to assign them unique type 
codes . 

Object Offset 

An object offset is a 32-bit ordinal used to specify a datum 
within an object. It is capable of pointing to either data 
or access descriptors in an object. An object offset is di- 
vided into a number of fields. The interpretation of these 
fields is dependent on the object representation. 

Object Size 

The size of an object is specified in encoded fields (50) of 
the object table entry (OTE) . The object offset (22) in a 
virtual address (20) plus the operand size is compared with 
the size of the referenced object on every address transla- 
tion. This operation is called bounds checking and prevents 
reference beyond the specified object of a datum which may 
belong to another object. 

Object Representation 

An object is described by the object table entry which pro- 
vides the mapping information for the physical addresses of 
the storage blocks and pages which together, directly or in- 
directly, represent the physical object. The system uses 
three different mapping schemes for different maximum object 
sizes and to minimize object representation overheads. 

Simpl Objects. A simple object is represented by a block in 
physical address space directly. The physical base address 
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is stored directly in the object table entry. Such an entry 
is called a simple obj ct descriptor. 

Paged Objects. A paged object is represented by a set of 
physical pages using a single-level page table. The object 
table entry for a paged object, called a paged object de- 
scriptor, contains the physical address of a page table, 
which is an array of page table entries for the pages. 

Bipaged Objects. A bipaged object is represented by a set 
of physical pages using two levels of page tables. As shown 
in FIGURE 1, the object table entry for a bipaged object, 
called a bipaged object descriptor, contains the physical 
address of a page table directory (60) , which is an array 
of page table entries for page tables, including the page 
table (44) shown. 

A simple object is defined by a simple object descriptor and 
represented by a single block. A simple object descriptor 
contains the physical base address and the block length. A 
simple object cannot span across a <1H byte physical address 
boundary. 

A simple object offset is partitioned as follows: 

Directory Index DI (bits 22-31) . This 10-bit field must be 
zero. Otherwise a PROTECTION fault is raised. 

Page Index PI (bits 12-21). This 10-bit field must be zero. 
Otherwise a PROTECTION fault is raised. 

Block Offset SO (bits 0-11) . This 12-bit field is the byte 
displacement added to the base address of the block to form 
the physical address for the first byte of the operand. 
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Paged objects 



A paged object is described by an object table entry called 
a paged-object descriptor. Paged objects are implemented 
with one level of page table. Each page is individually 
swappable and relocatable, thus not all pages of a paged ob- 
ject need be present in physical address space at the same 
time. To access an item of a paged object, only the page 
table and the selected page need to be located in the physi- 
cal address space. 

A paged-object descriptor contains the object length, but 
does not contain the base addresses (45) of the pages which 
represent the object. The base address field (45) of a 
paged-object descriptor contains the base address of the 
page table block. The length of the page table block is de- 
fined by the object length of the object. 

A paged object offset (22) is partitioned as follows: 

Directory Index, DI (bits 22-31) . This 10-bit field must be 
zero. Otherwise, a PROTECTION fault is raised. 

Page Index, PI (bits 12-21) . This 10-bit field is used to 
index into the selected page table (44) for a page table en- 
try. 

Page Offset, PO (bits 0-11) . This 12-bit field is the byte 
displacement and is appended to the base address (45) in the 
page table entry of the page to form the physical address 
for the first byte of the operand in the paged object (38). 



Bipaged Objects 



Refer to FIGURE 1. A bipaged object (38) is described by an 
object table entry (50, 52) called a bipaged object descrip- 



tor. Bipaged objects are implemented with two levels of page 
tables. Each page or page table is individually swappable 
and relocatabl , thus not all pages or page tables of a bi- 
paged object need be present in physical address space at 
the same time. To access an item of a bipaged object, only 
the page table, the selected page table, and the selected 
page need to be located in the physical address space. 

A bipaged object descriptor contains the object length, but 
does not contain the base addresses of the pages nor page 
tables which represent the object. The base address field 
(52) of a bipaged object descriptor contains the base ad- 
dress of the page table directory block (60) . The length of 
the page table directory block is defined by the object 
length of the object. 

A bipaged object offset is partitioned as follows: 

Directory Index, DI (bits 22-31) . The directory index (70) 
selects a page table entry in the page table directory 
specified by the bipaged object descriptor. 

Page Index, PI (bits 12-21) . The page index (72) selects a 
page table entry in the specified page table. 

Page Offset, PO (bits 11-0). The page offset (74) is used 
as an offset into the page. The page offset is appended to 
the base address (in a page table entry) to form the physi- 
cal address for the first byte of the operand. 

Object Lifetime 

To support the implicit deallocation of certain objects and 
to prevent dangling references, the system defines the con- 
cept of object lifetime. Dangling references can only occur 
if access descriptors which point to objects with shorter 
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lifetimes are stored in objects with longer lifetimes. The 
local object lifetime bit in the encoded fields portion of 
access descriptors, object descriptors, and page table en- 
tries are the means by which the system determines the life- 
time of an object and prevents a potential dangling-refer- 
ence access descriptor from being stored. 



Local Bits ' — 

A local bit is associated with each object to denote its 
relative lifetime. The local bit is located in the encoded 
fields portion of the object descriptor for the object, for 
example in the encoded fields (50) of the storage descriptor 
in the object table (42) . A value of 0 indicates a global 
object with unbound object lifetime. A value of l indicates 
a local object with bound object lifetime. 



Lifetime Checking 

Refer to FIGURE 7. The *ji3ject lifetime check is performed 
every time an AD is stored. Since this requires the life- 
time of the source AD and destination location to be com- 
pared, the operation is called lifetime checking. If a 
valid source AD has its associated local bit set to 1 and 
the lifetime of the destination location (in an object table 
entry or a page table entry) has its associated local bit 
set to 0 (is of global lifetime), a PROTECTION . LIFETIME 
fault is signalled. The destination location (s) may be mod- 
ified if there is no other protection fault, but the AD of 
local lifetime must never be stored in the destination. 

in FIGURE 7, the AD local bit in the encoded fields (35) of 
AD (24) is compared in OTE Lifetime Check Logic (150) with 
the destination object lifetime, the OTE local bit in the 
encoded fields (50) of the OTE access descriptor. The OTE 
local bit in the encoded fields (50) of the OTE is compared 
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in PDTE Lifetime Check Logic (152) with the destination ob- 
ject lifetime, the PDTE local bit in the encoded fields (62) 
of the PDTE access descriptor. The PDTE local bit in the 
encoded fields (62) of the PDTE is compared in PTE Lifetime 
Check Logic (154) with the destination object lifetime, the 
PTE local bit in the encoded fields (62) of the PTE access 
descriptor. If any of these checks fails, a protection 
lifetime fault (158) occurs at the output of the OR (156). 

in the implicit manipulation of system objects, lifetime 
checking is ignored unless explicitly specified. 

When an access descriptor is stored into memory, lifetime 
checking is performed first. When an access descriptor is 
written into memory, lifetime checking is not performed. 

flapp ing Tables 
Object Table Objects 

An object table object (42) serves as the root of the vir- 
tual address mapping. An object table is an array of 16-byte 
object table entries. The object index field (34) in the 
access descriptor (24) selects an object table entry in the 
object table (42) . Object table entries are described sub- 
sequently. 

Object tables do not have a system defined system type. Al- 
though an AD that is a pointer to an object table OT has 
global lifetime, the object table entries (OTEs) or page 
table entries of an object table (OT) must have local life- 
time. This is necessary to support Type Definition Object 
(TDO) ADs in OTEs and embedded descriptors. 

There is one system wide object table (OT) for all proces- 
sors which share a single system wide virtual address space. 
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System Defined Object Indices 
The following object indices are defined: 

Purpose 

Reserved for empty AD. 
Preserved 
Object Table 
Preserved 

Default TDO ADs for object types 0-15 



Object Indices 
0 

1-7 
8 

9-15 
16-31 



Page Tables or Page Table Directories 

Page tables (44) are used to provide one or two level (s) of 
mapping for paged objects and bipaged objects. Page table 
directories (60) are used to provide the first level of map- 
ping for bipaged objects. Page tables (or page table direc- 
tories) contain page table entries (or page table directory 
entries) which define the base address of a page, and other 
information for virtual memory management and garbage col- 
lection. 

Page tables and page table directories are system recog- 
nized, but are not objects and do not have a system type. 

A page table (44) is an array of page table entries, each of 
which is 4 bytes in length. Each page table entry in a page 
table describes a page in a paged object or a bipaged ob- 
ject. Each page table entry in a page table directory (60) 
describes a page table (44) for a bipaged object (38) . 

The page table of a paged object or the page table directory 
of a bipaged object can be variable in size and aligned on 
any 64-byte boundary. The page tables of a bipaged object 
must be 4K bytes in size and aligned on 4K bytes boundary. 
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Page tables and page tabl directory are not objects and 
thus cannot be accessed directly in the virtual address 
space. In one embodiment of the invention they are accessed 
using physical addresses. In another embodiment of the in- 
vention the page tables are mapped to part of the object 
they are defining. In the second approach, the physical ad- 
dress of the page table directory or the' page table is du- 
plicated, software guarantees that the physical address 
alias is updated during page swapping. 



Descriptor Formats 



Data Words 

The fields of a data word are defined as follows: 
Data (bits 0-31). This field contains any data value. 
Tag (Tag Bit) . This bit is 0 for data values. 
Access Descriptors Access descriptor 

The diagram of FIGURE 3 includes an access descriptor. Th« 
fields of an access descriptor are defined as follows: 

Read Rights (bit 0) . This bit indicates that reading the 
contents of the object referenced by this access descriptor 
is allowed. 

Write Rights (bit 1) . This bit indicates that writing the 
contents of the object referenced by this access descriptor 
is allowed. 
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Type Rights (bits 2-4) . The interpr tation of this 3-bit 
field is determined by the object type of the referenced ob- 
ject. 

of the bit bit position in the AD 

Type Rights 1 bit 2 

Type Rights 2 bit 3 

Type Rights 3 bit 4 

Local (bit 5). This bit indicates the object's lifetime. 
This bit is 0 for a global object and 1 for a local object. 

Object index (bits 6-31) . This 26-bit field selects an ob- 
ject table entry in the object table. 

Tag (Tag Bit) . This bit must be 1 for a valid access de- 
scriptor. 

Mixed Words 

A mixed word is the union of a data word and an access de- 
scriptor, i.e. a mixed word can be viewed as either a data 
word or an access descriptor depending on the context. 

The values of a mixed word are divided into the following 
classes: 

(1) Valid Access Descriptor. A valid access descriptor has 
the tag bit set to 1. This can be dereferenced (used to ref- 
erence the content of the object) if the object for the cor- 
responding index is defined. The CONSTRAINT. INVALID_AD 
fault is raised when the tag bit is 0 when an AD is ex- 
pected . 

(2) Data. A data word has the tag bit set to zero. When a 
data value is generated, the tag bit is always set to zero. 
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When a data value is expected, the tag bit is ignored and 
interpr t d as z ro. No fault is raised when the tag bit is 
1 when a data value is expected. 

Virtual Addresses 

FIGURE 3 is a diagram of a virtual address format. The 
fields of a virtual address are defined as follows: 

Object Offset (bytes 0-3) . This 32-bit field contains an Or- 
dinal offset into the object referenced by the access de- 
scriptor in the virtual address. 

Access Descriptor (bytes 4-7) . This AD specifies the object 
referenced by this virtual address. The AD also specifies 
the permissible operations using this virtual address. 

Object Table Entries 

An object table (42) can contain the following types of ob- 
ject table entries. All object table entries are 16 bytes 
in size. Specific object table entries are identified by 
the entry type field (bits 96-98) of each object table entry 
as follows: 

000 — Invalid Object Table Entry 

001 — Embedded Descriptor 

010 — Invalid Simple Object Descriptor 

011 — Simple Object Descriptor 

100 — Invalid Paged Object Descriptor 

101 — Paged Object Descriptor 

110 — Invalid Bipaged Object Descriptor 

111 — Bipaged Object Descriptor 

The last six object table entries are collectively called 
storage descriptors. The format of a storage descriptor is 
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shown in FIGURE 4. Valid storage descriptors contain physi- 
cal addresses. Invalid storage descriptors, where the base 
address field may not be valid, are used to indicate that 
the selected object cannot be accessed. 

The fields of a invalid simple object descriptor, a invalid 
paged object descriptor, or a invalid bipaged object de- 
scriptor are defined as follows: 

TDO AD (bits 32-63) . This field (51) contains the type defi- 
nition object AD associated with this object descriptor. 

Reserved (bits 68-69) . This field must be zero. 

Base Address (bits 70-95) . This 26-bit field (52) contains 
the physical base address (in units of 64 bytes) of the 
block, page table or page table directory. This provides a 
2**32 byte physical address space. This field is uninter- 
preted in an invalid storage descriptor. 

Entry Type (bits 96-98). This 3-bit field indicates the type 
of object table entries and the definition of the rest of 
the descriptor. 

Access Status (bits 99-103). This 5-bit field is described 
in the next section. This field is only defined in a simple 
object descriptor. This field is preserved for other entry 
types. 

Object Length (bits 114-119). This field contains the 
(encoded) length in units of 64 bytes of the storage block 
referenced by the base address field. 

The word "encoded" is used with a length field to indicate 
that the field contains the actual length minus one instead 
of the actual length. 
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In a simple object, this field contains the (encoded) length 
in units of 64 bytes d fin d by this descriptor. 



In a paged object descriptor, this field contains the 
(encoded) length in units of 64K bytes, or the number of 
page table entries in the page table (minus one)/16 defined 
by this descriptor. - 

In a bipaged object descriptor, this field contains the 
(encoded) length in units of 64M bytes, or the number of 
page table entries in the page table directory (minus 
one)/16 defined by this descriptor. 

Write Back (bit 122) . This bit enables write-back caching 
for the object if the segment or page is cacheable. 

Object Type (bits 124-127) . This 4-bit field encodes the ob- 
ject type of the object. 

Access Si ttus 

The access status field contains information for the manage- 
ment of blocks and pages. It is found in simple object de- 
scriptors and valid page table entries (PTEs) . This field 
does not appear in an invalid object descriptor, a 
paged/bipaged object descriptor, nor a page table directory 
entry (PTDE) . 

The 5 bits of the access status field shown in FIGURE 4 are 
defined as follows: 

Accessed (bit 99 in OTE, Bit 3 in PTE) . This bit indicates 
the object or page defined with this descriptor has been 
r f r need (read or write) . This bit is ensured to be 1 be- 
fore the associated storage is referenced. This bit is 



sticky (i.e. it is set implicitly by th system but never 
cleared) . 

Altered (bit 100 in OTE, Bit 4 in PTE) . This bit indicates 
the object or page defined with this descriptor has been 
overwritten. This bit is ensured to be 1 before the associ- 
ated storage is overwritten. This bit is sticky (i.e. it is 
set implicitly by the system but never cleared). 

Mixed (bit 101 in OTE, bit 5 in PTE or PTDE) . This bit indi- 
cates that an AD has been written in the object or page de- 
fined by this descriptor. This bit is ensured to be 1 be- 
fore the associated storage is overwritten with a non-zero 
tag bit. This bit is sticky (i.e. it is set implicitly by 
the system but never cleared) . 

Cacheable (bit 102 in OTE, Bit 6 in PTE) . This bit indicates 
the object or page defined with this descriptor can be 
cached. The encodings of the cacheable bit are as follows: 

0 - Do Not Cache 

1 - Can Be Cached. 

Local (bit 103 in OTE, bit 7 in PTE). This bit indicates the 
lifetime of the object or page defined by this descriptor. 
This is 0 for a global object or page and 1 for a local ob- 
ject or page. 

It may be necessary to set the accessed, altered, or mixed 
bits of the OTE/PTE in memory to ones on a memory access. 
The operation is performed using an atomic operation. The 
cacheability and local bits are never modified. It is per- 
missible to alter these bits even though the OTE/PTE re- 
turned by the atomic read is invalid as long as the OTE/PTE 
is valid on a previous read and a TLB invalidation operation 
has not been performed on the specific OTE/PTE. 
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When an OTE/PTE is invalidated by software, only the valid 
bit should be modifi d first becaus the accessed, altered 
and mixed bits may be modified at the same time. 

When the accessed, altered and mixed bits are updated in 
memory using RMW operations, the valid bit of the original 
OTE/PTE must not be altered.. _ 

Embedded Descriptors 

Embedded Object Descriptor 

An embedded descriptor holds special system-defined data 
structures. The only such data structure defined by the 
system is a semaphore. 

The fields of an embedded descriptor are defined as follows: 

Storage Area (bits 0-95) . This 12-byte area is used to rep- 
resent the data structure'.'' 

Entry Type (bits 96-98). This field is 2#001# for an embed- 
ded descriptor. 

Use Default TDO (bit 99) . If set, this descriptor has an as- 
sociated default TDO. If clear, the TDO AD is assumed to be 
in bits 32-63 of the descriptor, (software would normally 
set this bit in an embedded descriptor.) 

Type (bits 124-127) . The only value defined by the system 
is 0100, which indicates that the first three words hold a 
semaphore. 
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Invalid Obj ct Table Entry 



The fields of an invalid object table entry are defined as 
follows: 

TDO AD (bits 32-63). This field has the same interpretation 
as in a storage descriptor, but only if flag use-default-TDO 
is clear. 

Entry Type (bits 96-98) . This field is 2#000# for an invalid 
object table entry. 

Use Default TDO (bit 99) . If set , this descriptor has an as- 
sociated default TDO. If clear, the TDO AD is assumed to be 
in bits 32-63 of the descriptor. 

Object Type (bits 124-127) . This field has the same inter- 
pretation as in a storage descriptor. 

Page Table 1 Entries 

A page table or page table directory contains an array of 4- 
byte page table directory entries of similar format. Page 
table entries in a page table directory specify page tables 
while page table entries in a page table specify pages. 

The fields of a valid page table entry (PTE) or page table 
directory entry (PTDE) are defined as follows: 

Valid (bit 0) . This bit is 1 to indicate a valid page table 
entry or page table directory entry. 

Page Rights (bits 1-2). This 2 -bit field encodes the permis- 
sible operations (read or write) in different execution 
modes on the contents of this page (in a page table entry) 
or for the pages by this page table (in a page table direc- 
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tory entry) . Since a page may be controlled by more than one 
set of page rights, the effective rights is minimum of all 
page rights. 

Access Status (bits 3-7) . This 5-bit field is similar to 
that in a storage descriptor. This field is defined for a 
page table entry and is preserved for a page table directory 
entry. 

Base Address (bits 12-31) . This 20-bit field contains the 
physical base address (in units pages of 4096 bytes) of the 
page. 

The field of an invalid page table directory entry is de- 
fined as follows: 

Valid (bit 0) . This bit is 0 to indicates an invalid page 
table directory entry. 

Virtual Address Translation 

For a memory request, an instruction specifies an Access 
Descriptor, an Object Offset, whether it is a Read or a 
Write access, and the Length of the Request. 

The following describes the address translation of a virtual 
address to a physical address for accessing a paged object: 

(1) Compute the last byte of the memory request by adding 
the request length to the object offset. 

(2) Perform the request as two separate memory requests. 

(3) Determine the rep rights needed by the request type. 
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(4) Raise a PROTECTION fault if th rights needed are not 
presented in the read and write rights of the AD. 



(5) Read the object table entry selected by the object in- 
dex of the access descriptor. The entry type and valid 
bit are found in the encoded fields of the object table en- 
try. Raise a DESCRIPTOR fault if the entry type is not ap- 
propriate. Raise a VIRTUAL MEMORY fault if the object table 
entry is not a valid storage descriptor. 

(6) For this description it assumed that the object table 
entry is for a paged object. Raise a PROTECTION fault if 
the directory index and page index found in the offset por- 
tion of the address of the memory request is greater than 
the object length in the paged object descriptor found in 
the page table. 

(7) Scale the page index (bits 12-21 of the offset in the 
address) by 4 and add it to the base address in the object 
.descriptor (in the objec^. table) to form the physical ad- 
dress of the selected data page table entry (in the page 
table) . 

(8) Read the page table entry and raise a VIRTUAL_MEMORY 
fault if the page table entry is marked as invalid. 

(9) Raise a RIGHTS PROTECTION fault if the access descrip- 
tor rights are greater than the page rights. 

(10) Combine the page offset (bits 0-11 of the address off- 
set field) with the base address in the page table entry in 
the page table to form the physical address of the paged ob- 
ject referenced by the memory request. 
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Object Referenc Testing 
COMPARE_MIXED and CHECKJTAG 

The COMPARE^ MIXED instruction compares both ADs or data for 
equality. If both operands are ADs, the instruction tests 
whether they reference the same object. m If both operands 
are data, the instruction test whether the data value are 
equal. The CHECKJTAG instruction checks for the tag bit. 

In an untagged system in supervisor mode, the tag bit is 
assumed to be set in COMPARE_MIXED. 

In the Ada expression "access_type_variable = null" where AD 
is used to represent access variable, the CHECKJTAG should 
be used instead of the COMPARE^ MIXED with zero because any 
non-zero data values still cannot be used to reference an 
ob j ect . 

Access Descriptor Creation 

The protection system requires that the tag bit not be set 
to one arbitrarily, that lifetime checking not be bypassed, 
and that the mutator operation not be ignored. However, in 
certain controlled situations, system software needs to cre- 
ate an access descriptor (AD) for an existing object. This 
is accomplished by the CREATE_ACCESS_DESCRIPTOR instruction. 

The CREATE_ACCESS_ DESCRIPTOR instruction converts a data 
word to an AD. 

Object Addressing Instructions 
LOAD PHYSICAL ADDRESS 
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The load_PHYSICAL_ADDRESS instruction returns the physical 
address of the operand. 

Type Management and Access Control 
Typed Objects 

The present invention provides two typing mechanisms: sys- 
tem-type and extended-type. They are not mutually exclusive. 
System types can be viewed as predefined properties of the 
object, while the extended type provides an unique identi- 
fier of the type and allows for type-specific software de- 
fined functions. The system-type mechanism is to provide 
system type specific instructions, which require operands of 
specific system types. The extended-type mechanism supports 
user defined types. This allows software defined type spe- 
cific operations and extended-typed specific operations to 
verify an object's type before carrying out their prescribed 
functions. This facility supports the type-manager style of 
programming . 

The type definition object (74) normally contains a refer- 
ence (75) to a type manager domain object (71) that provides 
some type-specific procedures. 



Object Type Field 

The system type of an object is specified by the object : typ. 
field in its object descriptor (see application S N 07/455,625 
(D-1256). One of the system types is generic (i.e. a simple 
flat address space) which contains no architecture defined 
fields. 
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The encodings for the Object Type field are as follows: 



fncodina 


Obiect Tvoe 


(Binary) 




0000 


Generic 


0001 


Type Definition Object 


0010 


Process Object 


0011 


Domain Object 


0100 


reserved 


0101 


Port Object 


0110-0111 


reserved 


1000-1111 


available for system software 



The architecture defines one type value for an embedded de- 
scriptor: 0100, which denotes a semaphore. 

Type Definition Object (TDO) 

Refer to FIGURE 1. The extended type of an object (38) is 
specified by the type definition object's access descriptor 
(51) associated with the object descriptor in the object 
table (42) , either explicitly or via default. If a default 
type definition object (TDO) is to be used, the object index 
for the default TDO is 16 plus the type encoding of the ob- 
ject or embedded descriptor. For instance, for a semaphore, 
the default TDO is entry 20 in the object table. 

A type definition object contains a reference address (75) 
to the type manager domain (71) . The type manager domain 
(71) contains other information used to manage the instances 
of a particular object type. These type manager domains 
reference software defined, type specific operations, that 
are programmed as procedures (77) or, in some cases, as in- 
dependent processes. 
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The object index of the TDO AD (51) can also be used as an 
unique identifi r for the extend d type. In this manner, 
\xp to 2**26 (64 mega-) extended types can be defined. 

For system objects, while the object type is used to indi- 
cate the set of type specific instructions, the type defini- 
tion object can be used to provide software (i.e. procedu- 
ral) extensions to the architecture-defined? type specific 
operations. 

Different type definition objects may be associated with 
different instances of the same system object type. This 
permits software extensions to the architecture defined in- 
structions to be defined on a per instance basis. 

LOAD_TYPE_DEFINITION 

This instruction copies the type definition object AD asso- 
ciated with the object referenced by the source AD into the 
destination. If the object specified has a default TDO, an 
AD (with no type nor rep rights and specifying global life- 
time) to the default TDO is returned. 

Rights 

The architecture uses various rights bits to restrict the 
way in which an object or an AD may be manipulated. There 
are two sets of rights bits — one set is found in an AD and 
the other set is located in the various page table entries 
in the access (i.e. address translation) path. 

Different ADs can have different access rights to the same 
object. Rights on an access path are shared among all users 
of the access path. An AD can be easily duplicated with the 
same or less rights than the source AD. Since an access path 
cannot be similarly duplicated, the architecture makes any 
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change to rights in the access path aff ct all users of the 
access path. 

An AD contains the following rights bits: 

- Type Rights 

- Read Rights 

- Write Rights 

A page table entry in an access path contains the following 
rights bits: 

- Page Rights 
Type Rights 

The type rights of an AD define the permissible type-spe- 
cific operations for the object referenced by the AD. The 
interpretation of the type rights bits of an AD depends on 
tSie type of object referenced. The type rights bits for a 

eneric object are uninterpreted. The interpretation of the 
type rights bits for each system object are predefined. They 
are described in the individual system object descriptions 
throughout this specification. The uninterpreted type rights 
bits are preserved for software defined type rights and in- 
terpreted by individual software level type managers. 

Read and Write Rights in Access Descriptors 

The read rights control reading the content of the refer- 
enced object, while the write rights control writing. The 
actual permissible operations are also optionally determined 
by the page rights in page tables. This allows the support 
of inaccessible objects (i.e. no access for encapsulated ob- 
jects) , read-only objects, write-only objects, and read- 
wr iteabl ob j ects . 
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Execute rights ar not defined; only read rights are re- 
quired to execute an instruction in the execution environ- 
ment. 



Page Rights 

The page rights in a valid page table entry define the 
read/write rights of the page in a bipaged object or a 
paged object. Page rights are used to permit software de- 
fined areas or regions of the execution environment to have 
different access protection. 

Page rights are interpreted differently depending on the ex 
ecution mode of the current process and the PTE break mode 
of the processor. Page rights are defined as follows for 
the supervisor and user execution modes: 



PTE Break User Mode Supervisor Mode 

read-write (break on write) 
read-only 
read-write 
read-write 
read-write 

Page rights, instead of AD read/write rights, are used to 
protect the instruction areas of a linear address space 
from accidental modification. 

When the processor is in physical-addressing mode (address 
translation is disabled), rights checking is disabled. 



1 00 - read-write 

0 00 - no access 

X 01 — no access 

X 10 - read-only 

X 11 - read-write 
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As described above, the access rights for an item are de- 
fined by rights fields in each level of the access path. 
Each access path contains the following: 

Read and write rights in an AD. 

Page rights in the page table directory entry for a bipaged 
object. 

Page rights in the page table entry for a paged object or a 
bipaged object. 

The effective rights for an object address are the minimum 
of the rights in the access path. 

INSPECT_ACCESS 

The INSPECT_ACCESS instruction returns the effective page 
rights of the access path specified by the source address. 

Type Definition Object 

A type definition object (74) is used to control access 
rights amplification. A type definition object has a prede- 
fined system type. 

The type rights in an AD (51) for a type definition object 
are defined as follows: 



Type Right 1 Uninterpreted. 

Type Right 2 Amplify Rights: If the bit is l, the TDO may 

be used in the AMPLIFYJRIGHTS instruction. 

Type Right 3 Create Rights: If the bit is 1, the TDO may 

be used in the CREATE_ACCESS_DESCRIPTOR 
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instruction. 



The fields of the type definition object (74) shown in FIG- 
URE 1 are defined as follows: 

Super TDO (bit 0) . This bit is interpreted during rights 
amplification as follows: 

0 - This TDO can be used to amplify ADs for objects whose 

type matches that specified by this TDO. 

1 - This TDO can be used to amplify any AD. 

Extended (bit 1) . This bit is 1 if the TDO is used to manage 
objects having this object as their TDO ADs. This bit is 0 
if the TDO is used to manage objects having the same object 
type as specified in the TDO. 

This bit also allows a single TDO, to manage object of the 
specified object type independent of their TDO ADs. 

Object Type (bits 28 - 31) . This 4-bit field is defined to 
have the same format as the corresponding field in an object 
descriptor. In the AMPLIFY_RIGHTS instruction, this field 
is compared against the object type of the referenced object 
if the extended type and the super TDO bits are zero. 

Rights Manipulation 

Refer to FIGURE 8. Two instructions are defined to increase 
or decrease the access rights of an AD. A rights mask (170) 
is specified in the source_2 operand of the instruction dur- 
ing rights amplification and restriction. A rights mask has 
the same format as an access descriptor, except that the lo- 
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cal bit, the object index fi Id and the tag bit are not 
used. 

If the AMPLIFY_RIGHTS instruction (165) is decoded, access 
rights are amplified by logically-ORing, in the amplify 
rights logic (168), the access rights in the source AD (162) 
with those in the rights mask (170) . The logic flow within 
the amplify rights logic (168) of FIGURE 8 is shown in FIG- 
URE 9. 

If the KESTRICT_RIGHTS instruction (167) is decoded, , ac- 
cess rights are reduced by logically-ANDing, in the restrict 
rights logic (172), the access rights in the AD with the 
complement of that in the rights mask (170). The logic flow 
within the restrict rights logic (172) of FIGURE 8 is shown 
in FIGURE 10. 

The AMPLIFY_RIGHTS instruction requires a type definition 
object AD (51) with amplify rights. The AMPLI F Y_RIGHTS in- 
struction amplifies the rights of the source AD (162) as 
specified by the right-- mask (170) and stores the amplified 
AD in the destination (176) . 

The RESTRICT_RIGHTS instruction removes the rights of the 
source AD (174) as specified by the rights mask (170) and 
stores the restricted AD in the destination (176). 

The accessibility of an addressing environment can be re- 
stricted to those objects with the minimum required access 
rights- needed for the execution of the program. Instructions 
are provided to remove (or restrict) access rights that are 
not needed. Access restriction is typically performed before 
an AD is passed as a parameter to a procedure or returned as 
a result. 



-38- 



Certain (system or xtended) typed objects are manipulated 
exclusively by their corresponding type managers. An AD to a 
typed object, outside the domain of its type manager, usu- 
ally has limited access rights (e.g. no access or read-only 
rights) to prevent access to or modification of the object 
without the knowledge of the type manager. The type manager 
restricts (i.e removes) the access rights in the ADs, for 
objects of the type(s) under its control, before passing 
them outside its domain. When such an AD is returned to the 
type manager, the access rights are amplified (i.e. in- 
creased) while inside the domain to allow modification, of 
.the referenced object, by the type manager. 

AMPLIF¥_RIGHTS instruction 

Refer to FIGURE 9 which is a diagram of data flow within the 
amplify rights logic of FIGURE 8 for an understanding of the 
following description of the AMPLIFY_RIGHTS instruction. 

Operation: Amplifies, under control of a type definition 
object, the specified rights bits in the specified source AD 
and stores the amplified Ad in the destination. 
Opcodes : 
amplify 

653 REG source_l(val:m) source_2 (val:0) src/dst (vds:m) 
source_l type definition object 

source__2 rights__mask 
src/dest source/destination 

Action: 

Check the tag bit of the TDO AD (202). Raise a C0N- 
STAINT_INVALID AD if the tag bit of the source AD is zero 
(204) . 
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Check th typ rights field to see if amplify rights are 
specifi d (206) . If not, assert a PROTECTION TYPE RIGHTS 
fault (208) . 

Check the super TOO bit (210) . If the super TDO bit in 
the TDO is one, go to logic block (218. If the super TDO 
bit in the TDO is zero and the extended bit is one (212) , 
raise a TYPE. MISMATCH FAULT (216) . 

Compare the object type of the source object with the object 
type controlled by the TDO (214). If different, and the su- 
per TDO bit in the TDO is zero (21) and the extended bit is 
zero (212) , then raise a TYPE. MISMATCH FAULT (216) . 

If the object type of the source object with the object type 
controlled by the TDO (214) are the same, then Logically OR 
the read, write and type bits of the source AD and the cor- 
responding bits in the rights mask to form the type rights 
of the destination AD (218) . 

RESTRICT_RIGHTS instruction 

Refer to FIGURE 10 which is a diagram of data flow within 
the restrict rights logic of FIGURE 8 for an understanding 
of the following description of the RESTRICTJRIGHTS instruc- 
tion. 

Operation: Restricts the specified rights bits in the spec- 
ified source AD and stores the Restricted AD in the destina- 
tion. . 
Opcodes : 
restrict 

652 REG source_2(val:0) src/dst (vds:m) 
source_2 rights__mask 
src/dest source/destination 
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Action: 



Check the type rights field to see if restrict rights are 
specified (252). If not, assert a PROTECTION TYPE RIGHTS 
fault (254). 

If the tag bit of the source is zero (256) skip the follow- 
ing rights restriction actions and store the data segment in 
the destination (260) . 

If the tag bit of the source is one (256) remove the read, 
write and type bits of the source AD whose corresponding 
rights bits in the rights mask are one (260) . Store the re- 
stricted AD in the destination (260) . 

Cacheable 

The cacheable bit is defined to prevent "caching" of an ob- 
ject or a page. This bit is one if caching is allowed, 
zero otherwise. Caching allows delaying a memory access 
(e.g. write back), and grouping contiguous memory accesses 
into a single memory transaction (e.g. cache fill) . If 
caching is disabled, memory accesses are passed directly to 
the physical memory without any modification. 

In a system with memory mapped device registers, the 
cacheable bit for the page or object should be zero. It may 
also be used to prevent external caching of instruction re- 
gion to avoid double caching, or to prevent caching of 
shared objects to avoid unnecessary caching traffic. 

The cacheable bit in a simple object descriptor or a page 
table entry indicates whether the contents of the refer- 
enced object or page can be cached. 
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While the invention has been particularly shown and de- 
scribed with reference to preferred embodiments thereof, it 
will be understood by those skilled in the art that the 
foregoing and other changes in form and detail may be made 
therein without departing from the scope of the invention. 
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CLAIMS 

1. A data processing system including a memory 
space (10) and a processor register space (11) in a proces- 
sor of said data processing system for storing object de- 
scriptors having base and length information stored therein 
for use in locating objects in said memory space, 

said processor being capable of communicating with said 
memory space (10) and capable of executing an operation by 
means of an operator specified in an instruction (14); 

a plurality of addressable objects, including a bipaged 
object (38) , said objects being stored in an address space 
of said memory space, 

said plurality of addressable objects including in- 
struction objects comprised of instructions including said 
instruction (14) defining an operation; 

an address (20) referenced in said instruction, said 
address being specified as an offset (22) and an access de- 
scriptor (24) ; 

said plurality of objects including an object table 
(42), a page table directory (60) , and a page table (44); 

each of said objects being comprised of words, said 
words being either access descriptors (30) or data words 
(32); 

each of said access descriptors including 

1. an object index for selecting an object in said ad- 
dress space, 

2. a rights field, said rights field specifying the 
permissible operations on an object selected by said access 
descriptor ; 
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said data proc ssing system cbaract ris d by: 

ach of said access descriptors including an AD life- 
time bit for indicating the lifetime of an object sp cified 
by said access descriptor; 

said object table object (42) being stored at an ad- 
dress accessible by said processor upon processor initial- 
ization, 

said object table having stored therein object descrip- 
tors for use by said processor in forming physical addresses 
to said page table directory object (60) , 

each of said object descriptors including a first en- 
coded field (50) specifying the base address of the object 
referenced by said object descriptor and a second encoded 
field (52) which includes page rights; 

said object storage descriptor includes a lifetime bit 
for indicating the lifetime of said object selected by said 
access descriptor; 

said page table (44) having stored therein page table 
entries for use by said processor in forming physical ad- 
dresses to said paged object (38) , 

each page table entry having a page rights field (81) ; 

said offset (22) including a page index (PI) used to 
index into a selected page table to locate said page table 
entry, and a page offset (PO) used in conjunction with a 
base address (79) stored in said page table entry to locate 
a datum entry in said paged object (38) ; and, 

means (150) for comparing said AD lifetime bit of said 
access descriptor with the said OTE lifetime bit of said 
object table entry and for asserting a fault upon the condi- 
tion that the access permitted by said AD lifetime bit of 
said access descriptor is inconsistent with said OTE life- 
time bit of said object table entry. 

2. The combination in accordance with claim 1 
wherein said AD lifetime bit for indicating the lifetime of 
an object specified by said access descriptor comprises a 
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Local bit (bit 5), said local bit having a value of 0 indi- 
cates a global object with unbound object lifetime and said 
local bit having a value of 1 indicates a local object with 
bound object lifetime. 

3. The combination in accordance with claim 2 
wherein wherein said means (150) for comparing said AD life- 
time bit of said access descriptor with the said OTE life- 
time bit of said object table entry includes means for as- 
serting a PROTECTION. LIFETIME fault upon the condition that 
said AD has its associated local bit set to 1 and the life- 
time bit of said object table entry (OTE) has its associated 
local bit set to 0 (is of global lifetime). 

4. A data processing system substantially as hereinbefore 
described with reference to the accompanying drawings. 
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